Meta content delivery network system

ABSTRACT

A meta content delivery network system provides a Meta CDN DNS (MCD) server that performs scheduling for multiple content delivery networks (CDN) and is authoritative for all domains given to the CDNs. The MCD contains information about CDNs which participate in each CDN domain names. Each CDN provides to the Meta CDN a domain name that will refer to their CDN&#39;s portion of the entire Meta CDN for that Meta CDN customer. The MCD receives domain name query requests from local DNSs and selects the proper CDN address based on a predefined capacity reservation of CDNs and statically mapped preferences for certain clients and directs the local DNS requests to the proper CDN address.

BACKGROUND OF THE INVENTION

[0001] 1. Technical Field

[0002] The invention relates to network traffic management in a computerenvironment. More particularly, the invention relates to trafficscheduling between multiple independent content delivery networks in acomputer environment.

[0003] 2. Description of the Prior Art

[0004] A Content Delivery Network (CDN) is collection of caching,streaming, storage, and other servers distributed throughout theInternet in order to deliver content closer to the end user, avoidingthe “middle mile” problem.

[0005] CDN's provide two main benefits to their users (in this case theuser is the customer or content owner, not the end user). The first isreduction of traffic at the origin site. Every request that arrives atthe CDN is a request not arriving at the origin site. This means thatthe origin site will have less work to do as it utilizes the CDN moreand more. In addition, the type of work that is being removed is oftenvery different than what will continue to be directed at the originsite. As an example, all of the requests for images which result in manyconnections to a server are removed from the origin while connectionsthat need access to the database remain. This allows the origin site tobe tuned for the database type requests that it will be receiving. A CDNof at least one POP will provided this benefit to a customer.

[0006] The second benefit is increased performance for the delivery ofthe content by reducing the network delay between the browser and thecontent. This is done by placing servers in locations near the end usersand using a system to direct end users to the “best” server. Eachcustomer will have a different group of end users. Some will need fullglobal coverage while other may only need certain parts of the world.

[0007] A network provider building their own CDN has a very costeffective solution for solving the first problem of reducing origin siteload. Owning their own network, they often see their internal costs forusing it as very low, and as a result can price a CDN solution very low.The ability of a given network provider to solve the second issue withonly their own connectivity, will not work for all customers.

[0008] Today there are two types of CDNs generally available:facilities-based CDNs (also referred to as an on-net CDN) andmulti-network CDNs. A facilities-based CDN has deployment limited to asingle service provider's network and points of presence (POPs). Amulti-network, CDN has servers distributed on many different serviceprovider networks and POPs.

[0009] In general, multi-network CDNs provide higher performance,availability, redundancy, and scalability than facilities-based CDNs,due to the fact that no one service provider network controls all thecontent providers (servers) and/or the eyeballs (clients). Also, notmany service providers have sufficient coverage and POPs to distributeand deliver content. Thus, a multi-network CDN will outperform afacilities-based CDN in all cases.

[0010] However, some service providers still want to create afacilities-based CDN in order to maintain traffic on their own networkas well as to participate in this new and growing market. There is aneed to provide the facilities-based CDN providers the advantages ofmulti-network CDNs.

[0011] It would be advantageous to provide a meta content deliverynetwork system that provides load balancing and traffic schedulingacross independent CDNs in a computer network. It would further beadvantageous to provide a meta content delivery network system thatallows CDN providers to designate the availability of their networks.

SUMMARY OF THE INVENTION

[0012] The invention provides a meta content delivery network system.The system provides load balancing and traffic scheduling acrossmultiple content delivery networks (CDN) in a computer network. Inaddition, the invention allows CDN providers to designate theavailability of their networks and to assign clients to specific CDNs.

[0013] A preferred embodiment of the invention provides a Meta CDNscheduling layer above multiple content delivery networks (CDN). Thiscombined Meta CDN provides customers with the combined scale and reachof all the underlying CDNs.

[0014] Meta CDN scheduling is performed by a Meta CDN DNS (MCD) server.The MCD server is authoritative for all domains given to customers ofthe Meta CDN service. The MCD contains information about which CDNsparticipate in which CDN domain names. Each CDN provides to the Meta CDNa domain name that will refer to their CDN's portion of the entire MetaCDN for that Meta CDN customer.

[0015] The MCD receives domain name query requests from local DNSs. Itselects the proper CDN address based on a predefined capacityreservation of CDNs and statically mapped preferences for certainclients and directs the local DNS requests to the proper CDN address.

[0016] The local DNS finds which DNS server is authoritative for the CDNaddress and sends a request to that authoritative DNS server. Theauthoritative DNS server performs load balancing for the servers withinits CDN and returns an A record to the local DNS which forwards the Arecord to the requesting client. The requesting client uses the A recordto make a request to a server within the proper CDN.

[0017] The MCD defines weights for each CDN which are used to control aweighted scheduling algorithm for the CDNs. The weights are dynamicallyadjusted to change CDN priorities.

[0018] Alternatively, the MCD allocates Name Server (NS) recordsdynamically to the local DNS. Each CDN keeps the MCD updated with all ofthe scheduling devices that each CDN uses.

[0019] Other aspects and advantages of the invention will becomeapparent from the following detailed description in combination with theaccompanying drawings, illustrating, by way of example, the principlesof the invention.

BRIEF DESCRIPTION OF THE DRAWINGS

[0020]FIG. 1 is a block schematic diagram of an on-net architectureaccording to the invention;

[0021]FIG. 2 is a block schematic diagram of an overlay architectureaccording to the invention;

[0022]FIG. 3 is a block schematic diagram of a content proxying exampleaccording to the invention;

[0023]FIG. 4 is a block schematic diagram of a Meta CDN scheduling layerabove multiple CDNs according to the invention;

[0024]FIG. 5 is a block schematic diagram of an authoritative Meta CDNDNS (MCD) server for a group of CDNs according to the invention; and

[0025]FIG. 6 is a block schematic diagram of an exemplary MCD loadbalancing and redirection packet flow according to the invention.

DETAILED DESCRIPTION OF THE INVENTION

[0026] The invention is embodied in a meta content delivery networksystem in a computer environment. A system according to the inventionprovides load balancing and traffic scheduling across multiple contentdelivery networks (CDN) in a computer network. In addition, theinvention allows CDN providers to designate the availability of theirnetworks and to assign clients to specific CDNs.

[0027] The invention provides a Meta Content Delivery Network (CDN) DNSserver that enables multiple independent CDN providers to maximize thebandwidth of their network as well as their revenue.

[0028] CDNs are a collection of servers deployed at different points onthe Internet. A scheduling layer is provided above them that determineswhich server a given client should use. This scheduling is based on theload/availability of each server and their relative proximity, orlatency, to the clients (users). By directing clients to the leastloaded and lowest latency server, download time is greatly reduced aswell as the load on the origin servers.

[0029] There are two main architectures in use by CDNs: on-net andoverlay. Both methods have the CDN as authoritative for the domain nameto be accelerated through DNS. Varying degrees of importance are placedon the role DNS takes in making the actual server selection.

[0030] On-Net Architecture

[0031] Referring to FIG. 1, an on-net deployment is a collection ofservers 102, 103, 104, 105 arranged around the edge of a single network101. This allows content to be served from the “on network” side ofpeering points, reducing the traffic across the backbone of the onnetwork. In addition, it places servers 102, 103, 104, 105 close toclients 106, 107, 108, 109, 110 who are on network. Since the serversexist on a single network, routing techniques can be used to directclients to the server with the least latency to a given client. This canbe achieved by broadcasting routes for the IPs of the servers out allinterfaces that connect this network to other networks. This causes offnet client requests to find the closest entry point to the on networkwhere they immediately find a server with that IP. Because the CDN ownsthe network, it is able to deploy servers in locations such as peeringpoints to make the service compelling. Network traffic still needs tocross the peering point for clients that originate from off net.

[0032] Overlay Architecture

[0033] With respect to FIG. 2, overlay networks deploy their serversacross multiple networks 202, 203, 204, 205. Because these deploymentsspan networks 202, 203, 204, 205, scheduling using routing tricks isdifficult or impossible. Instead, overlay architectures are usuallydesigned around a smart DNS server 201 that makes the determination ofwhere to send users at DNS resolution time.

[0034] The smart DNS server 201 uses the source IP address of the clientmaking the request to determine latency from the client to servers inthe network. The Smart DNS server 201 also uses server load andavailability information to direct the client to the best possibleserver.

[0035] Domain Names

[0036] In both architectures, to have content served from a CDN, thecontent must be under a domain that the CDN is authoritative for. Thisis done by the content owner delegating a domain name to the CDN or bythe CDN creating a name in their domain for the customer to use. Thelatter tends to work better as it avoids any possible misconfigurationof the DNS on the part of the content owner.

[0037] The CDN has to understand what type of content the customer needsto support and may have content types mapped into domain names. In otherwords, when the customer wants to use the CDN for SSL content, they mayuse the hostname ssl-customer.cdn.com. For HTTP content, they may usethe hostname http-customer.cdn.com. This allows the CDN to havespecialized servers for different types of content.

[0038] Protocol Support

[0039] Communication on the Internet takes multiple forms, HTTP, SSL,FTP, streaming media, etc. CDNs, since they are not the creators of thecontent, cache content on behalf of the creator. Not all CDNs supportall content types, or if they do, they may go about supporting aprotocol using different solutions.

[0040] How Content Gets In

[0041] There are typically two methods for getting content into a CDN;proxying and publishing. The different methods are chosen for differentreasons based on the way the content will be used.

[0042] Content Proxying

[0043] Rferring to FIG. 3, using content proxying, origin servers 301,302, 303, keep master copies of content and CDN servers 303, 304, 305,306 cache content. Requests sent to CDN servers include enoughinformation to allow them to fetch the content from the origin serversif the content is not already cached.

[0044] The mapping of requested content to origin content isaccomplished using multiple methods and is protocol dependent. HTTP andSSL protocol requests normally use one of two methods: embedded URLinformation and Host directive mapping. As a real example of each,consider a single piece of content we wish to have served from a CDN:

[0045] http://www.customer.com/path/to/object.gif

[0046] If the content is going to be mapped to the origin site by thehost directive the CDN URL would look like this:

[0047] http://customer.cdn.com/path/to/object.gif

[0048] CDN servers would notice the HTTP host header customer.cdn.comand would have a table that maps it to www.customer.com.

[0049] Host based directive approaches have a few draw backs. First, adifferent CDN domain name needs to be given for each customer originsite. Second, all webcaches have to be updated with information in someway to add a new customer to the system. Finally, clients that do notsend the host directive in their request will not be able to besupported with this solution.

[0050] If the content is going to be mapped to the origin site usingembedded URL information, the CDN URL could look like this:

[0051] http://customer.cdn.com/www.customer.com/path/to/object.gif

[0052] In this solution, the CDN server can find the name of the originsite in the request (in this case in-between the first two slashes).This approach reduces the complexity of having to ensure that the CDNservers have access in some way to the host directive mapping and solvesthe problem of supporting clients that do not send a host directive intheir requests. This approach requires changing the URLs that refer tothe content to a URL formatted as above.

[0053] Content Publishing

[0054] Using content publishing, CDN servers are thought of like originsites. An external mechanism is used to ensure the CDN servers are insync with the origin site. This could be thought of as a mirroringsolution. It tends to work well for large file size content or protocolsthat do not lend themselves well to proxying.

[0055] Meta Content Delivery Network

[0056] With respect to FIG. 4, the Meta CDN 401 provides a schedulinglayer above multiple content delivery networks 402, 403, 404, 405, 406.This combined Meta CDN 407 provides customers with the combined scaleand reach of all the underlying CDNs. The benefits to the customer isgreater than that which can be provided by any of the underlying CDNs.

[0057] Architecture

[0058] Referring to FIG. 5, Meta CDN scheduling is performed by a MetaCDN DNS (MCD) server 501. The MCD server 501 is authoritative for alldomains given to customers of the Meta CDN service 502.

[0059] Scheduling

[0060] The MCD is provided with information about which CDNs participatein which CDN domain names. Each CDN provides to the Meta CDN a domainname that will refer to their CDN's portion of the entire Meta CDN forthat Meta CDN customer. Table I shows an example of the information usedby the MCD to correlate Meta CDN domain names to the proper CDN. MetaDomain CDN-1 Domain CDN-2 Domain CDN-3 Domain Customer1.meta.comCustomer1.cdn-1.com Customer1.cdn-2.com Customer1.cdn-3.comCustomer2.meta.com Customer2.cdn-2.com Not used Customer2.cdn-3.com

[0061] With respect to FIG. 6, an example of the MCD operation is shown.Redirection, or load-balancing operates as follows:

[0062] 1. The browser 606 sends a request 601 to its local DNS 607 forcustomer1.meta.com

[0063] 2. The local DNS 607 goes through DNS and finds the Meta DNSserver (MCD) 608 to be authoritative for this domain and sends a query602 to the MCD 608. The MCD 608 looks at the request and returns ananswer based on predefined capacity reservation and statically mappedpreferences for certain clients 602. An example of this is if one of theCDNs is known to be better suited to server requests from a particularISP, it will be mapped to do so. The answer comes from the Meta DNS inthe form of a CNAME. The Meta DNS controls the TTL on the CNAME and thuscontrols how long a user is scheduled to a particular CDN. In thisexample, from Table I, the answer is customer1.cdn-1.com.

[0064] 3. The local DNS 607 finds who is authoritative forcustomer1.cdn-1.com and sends a request 603 to the DNS server of CDN-1609. The DNS for CDN-1 609 performs the load balancing for the serverswithin CDN-1 and returns an A record 603 to the local DNS 607.

[0065] 4. The local DNS 607 returns this A record 604 to the client 606.

[0066] 5. The client 606 makes a request 605 to the server within CDN-1611.

[0067] Domain Names

[0068] The Domain Name that the customer uses is controlled by the MetaCDN. Issues such as failed page loads can result if sites use any of theunderlying CDN domain names to reference CDN content.

[0069] Protocol Support

[0070] The Meta CDN supports any Protocol of the underlying CDNs. Any ofthe CDNs that do not support a particular protocol will not be scheduledto for those domain names.

[0071] How Content Gets In

[0072] Content never enters the Meta CDN but instead enters each of theunderlying CDNs directly through the method used for a particularprotocol. This is very simple for “pull” based protocols like HTTP andHTTPS, but requires a Meta CDN entry point for “push” content.

[0073] Problems Solved

[0074] This invention solves many of the problems that are encounteredin an independent CDN situation.

[0075] The Meta CDN schedules to the CDN's scheduling devices, givingthe CDN the final decision of which server within to utilize. Byreturning a CNAME, it is up to the client to find the deviceauthoritative for the name. The Meta CDN can alternatively give out NSrecords dynamically, requiring that each CDN keep the Meta CDN in syncwith all of the scheduling devices that they use.

[0076] The Meta CDN controls how long a user will be handed off to a CDNbefore the Meta CDN has the chance to change this decision. The namethat the client is looking up is the name Meta CDN name. Any TTLs givenout by each CDN on their records will not affect the Meta CDN's abilityto redirect users.

[0077] On a per customer basis, the Meta CDN decides which CDNs acustomer will be able to utilize. The Meta CDN maps Meta Hostnames toany amount of the CDNs. This can be done for different billing issues,as well as for feature support.

[0078] The Meta CDN can pre map customers to a specific CDN. The MetaCDN allows static mapping tables to be updated on a client IP basis.This allows the Meta CDN operator to determine which CDN they want thetraffic for the source IP sent.

[0079] The amount of traffic to be scheduled to each CDN by the Meta CDNcan be based on percentages. A simple user interface is available to theoperator from the CDNs to indicate their availability to accept moretraffic. The Meta CDN provides the ability to defines weight for eachCDN. These weights act to control a weighted round robin schedulingalgorithm in the Meta CDN. In addition, a simple interface is providedto allow each CDN to indicate to the Meta CDN their availability.Weights are also dynamically allocated to allow for adjustments. TheMeta CDN has the ability to reserve capacity of CDNs to ensure trafficflow.

[0080] Since the Meta CDN redirects traffic to and from CDNs, it has theability to get billing information directly from the redirected traffic.This enables the Meta CD N provider to accurately bill for the amount oftraffic that is redirected for any customer. Each CDN generates billinginformation for each Meta CDN customer and provides it to the Meta CDN.The Meta CDN aggregates the billing information for each customer. TheMeta CDN provides a simple user interface for the operator to retrieveand report billing information and administrate billing parameters.

[0081] Although the invention is described herein with reference to thepreferred embodiment, one skilled in the art will readily appreciatethat other applications may be substituted for those set forth hereinwithout departing from the spirit and scope of the present invention.Accordingly, the invention should only be limited by the claims includedbelow.

1. A process for scheduling traffic and load balancing between aplurality of Content Delivery Networks (CDN), comprising the step of:providing a Meta CDN Domain Name Server (DNS) server; wherein said Metaserver is the authoritative for all of the domains of said CDNs; whereinsaid Meta server provides a scheduling layer above said CDNs; whereinsaid Meta server directs local DNS requests to the proper CDN; whereinsaid Meta server records the domain names that each CDN participates in;wherein said Meta server receives domain name query requests from localDNSs; and wherein said Meta server returns a CDN domain address based ona predefined capacity reservation of CDNs and statically mappedpreferences for certain clients.
 2. The process of claim 1, wherein aclient's local DNS finds which DNS server is authoritative for said CDNdomain address and sends a request to that authoritative DNS server. 3.The process of claim 2, wherein said authoritative DNS server performsload balancing for the servers within its CDN and returns an A record tosaid local DNS.
 4. The process of claim 3, wherein said local DNS sendssaid A record to the requesting client; and wherein the requestingclient uses said A record to make a request to a server within theproper CDN.
 5. The process of claim 1, wherein said Meta server definesweights for each CDN; and wherein said weights are used to control aweighted scheduling algorithm for said CDNs.
 6. The process of claim 5,wherein said weights are dynamically adjusted to change CDN priorities.7. The process of claim 5, wherein each CDN indicates its availabilityto accept more traffic to said Meta server.
 8. The process of claim 1,further comprising the step of: aggregating billing information for aMeta CDN customer; wherein each CDN reports to said Meta server, thebilling information for said Meta CDN customer; and wherein said billinginformation is determined by the amount of traffic redirected to a CDN.9. The process of claim 8, further comprising the step of: providing auser interface for an operator to retrieve and report billinginformation and administrate billing parameters.
 10. A process forscheduling traffic and load balancing between a plurality of ContentDelivery Networks (CDN), comprising the step of: providing a Meta CDNDomain Name Server (DNS) server; wherein said Meta server is theauthoritative for all of the domains of said CDNs; wherein said Metaserver provides a scheduling layer above said CDNs; wherein said Metaserver directs local DNS requests to the proper CDN; and wherein saidMeta server records the domain names that each CDN participates in. 11.The process of claim 10, wherein said Meta server receives domain namequery requests from local DNSs; and wherein said Meta server returns aCDN domain address based on a predefined capacity reservation of CDNsand statically mapped preferences for certain clients.
 12. The processof claim 11, wherein a client's local DNS finds which DNS server isauthoritative for said CDN domain address and sends a request to thatauthoritative DNS server.
 13. The process of claim 12, wherein saidauthoritative DNS server performs load balancing for the servers withinits CDN and returns an A record to said local DNS.
 14. The process ofclaim 13, wherein said local DNS sends said A record to the requestingclient; and wherein the requesting client uses said A record to make arequest to a server within the proper CDN.
 15. The process of claim 10,wherein said Meta server allocates Name Server (NS) records dynamically;and wherein each CDN keeps said Meta server updated with all of thescheduling devices that each CDN uses.
 16. The process of claim 10,wherein said Meta server defines weights for each CDN; and wherein saidweights are used to control a weighted scheduling algorithm for saidCDNs.
 17. The process of claim 16, wherein said weights are dynamicallyadjusted to change CDN priorities.
 18. The process of claim 16, whereineach CDN indicates its availability to accept more traffic to said Metaserver.
 19. The process of claim 10, further comprising the step of:aggregating billing information for a Meta CDN customer; wherein eachCDN reports to said Meta server, the billing information for said MetaCDN customer; and wherein said billing information is determined by theamount of traffic redirected to a CDN.
 20. The process of claim 19,further comprising the step of: providing a user interface for anoperator to retrieve and report billing information and administratebilling parameters.
 21. An apparatus for scheduling traffic and loadbalancing between a plurality of Content Delivery Networks (CDN),comprising: a Meta CDN Domain Name Server (DNS) server; wherein saidMeta server is the authoritative for all of the domains of said CDNs;wherein said Meta server provides a scheduling layer above said CDNs;wherein said Meta server directs local DNS requests to the proper CDN;wherein said Meta server records the domain names that each CDNparticipates in; wherein said Meta server receives domain name queryrequests from local DNSs; and wherein said Meta server returns a CDNdomain address based on a predefined capacity reservation of CDNs andstatically mapped preferences for certain clients.
 22. The apparatus ofclaim 21, wherein a client's local DNS finds which DNS server isauthoritative for said CDN domain address and sends a request to thatauthoritative DNS server.
 23. The apparatus of claim 22, wherein saidauthoritative DNS server performs load balancing for the servers withinits CDN and returns an A record to said local DNS.
 24. The apparatus ofclaim 23, wherein said local DNS sends said A record to the requestingclient; and wherein the requesting client uses said A record to make arequest to a server within the proper CDN.
 25. The apparatus of claim21, wherein said Meta server defines weights for each CDN; and whereinsaid weights are used to control a weighted scheduling algorithm forsaid CDNs.
 26. The apparatus of claim 25, wherein said weights aredynamically adjusted to change CDN priorities.
 27. The apparatus ofclaim 25, wherein each CDN indicates its availability to accept moretraffic to said Meta server.
 28. The apparatus of claim 21, furthercomprising: a module for aggregating billing information for a Meta CDNcustomer; wherein each CDN reports to said Meta server, the billinginformation for said Meta CDN customer; and wherein said billinginformation is determined by the amount of traffic redirected to a CDN.29. The apparatus of claim 28, further comprising: a user interface foran operator to retrieve and report billing information and administratebilling parameters.
 30. An apparatus for scheduling traffic and loadbalancing between a plurality of Content Delivery Networks (CDN),comprising: a Meta CDN Domain Name Server (DNS) server; wherein saidMeta server is the authoritative for all of the domains of said CDNs;wherein said Meta server provides a scheduling layer above said CDNs;wherein said Meta server directs local DNS requests to the proper CDN;and wherein said Meta server records the domain names that each CDNparticipates in.
 31. The apparatus of claim 30, wherein said Meta serverreceives domain name query requests from local DNSs; and wherein saidMeta server returns a CDN domain address based on a predefined capacityreservation of CDNs and statically mapped preferences for certainclients.
 32. The apparatus of claim 31, wherein a client's local DNSfinds which DNS server is authoritative for said CDN domain address andsends a request to that authoritative DNS server.
 33. The apparatus ofclaim 32, wherein said authoritative DNS server performs load balancingfor the servers within its CDN and returns an A record to said localDNS.
 34. The apparatus of claim 33, wherein said local DNS sends said Arecord to the requesting client; and wherein the requesting client usessaid A record to make a request to a server within the proper CDN. 35.The apparatus of claim 30, wherein said Meta server allocates NameServer (NS) records dynamically; and wherein each CDN keeps said Metaserver updated with all of the scheduling devices that each CDN uses.36. The apparatus of claim 30, wherein said Meta server defines weightsfor each CDN; and wherein said weights are used to control a weightedscheduling algorithm for said CDNs.
 37. The apparatus of claim 36,wherein said weights are dynamically adjusted to change CDN priorities.38. The apparatus of claim 36, wherein each CDN indicates itsavailability to. accept more traffic to said Meta server.
 39. Theapparatus of claim 30, further comprising: a module for aggregatingbilling information for a Meta CDN customer; wherein each CDN reports tosaid Meta server, the billing information for said Meta CDN customer;and wherein said billing information is determined by the amount oftraffic redirected to a CDN.
 40. The apparatus of claim 39, furthercomprising: a user interface for an operator to retrieve and reportbilling information and administrate billing parameters.